エクストリームプログラミング読書会 第八回

第８回

参加者：@kkd, @ueda, @got4416, @kobatomo

進捗：7章 継続的インテグレーション〜8章 結論 まで(8ページ)

近況

@ueda

約20年ぶりの京都。京都駅ビルが昨年11月で開業２０周年だそうです。

ちなみに当時はF社のプロジェクトでM社向けの業務アプリ(VB+Oracle)をやっていました。

「最後はなぜかうまくいくイタリア人」を読みました。何事も30分から1時間は普通に遅れるそうで...。> 根本的に欠けている、分業の概念

悲惨な状況でも喜びを見出すイタリアン・シンキング

などなど、なかなかインパクトのある見出しが並んでいます。

@kobatomo

1/31 にt_wada氏とあう。2018年TDDBC開催を約束。一緒に参加したメンバが早速、TDD本を買っていた。

ライブコーディングを見て、テストがドキュメントになる瞬間が非常に勉強になった。

３年後の誰かのためを考え、リファクタリングできていない機会に出会えた。

テストを減らすことができていない機会に出会えた。

テストコードのメンテナンスコストが増加している現状。

2/1 〜 Python Boot Camp のコアスタッフとなるー。各会場の開催サポートをしていく。

@got

絶賛レガシーコードのテスト中！ Perl CGI サーバーが変わる...?

テスト仕様書にらめっこ

@kkd

18日間走らずに愛媛マラソンに参加。完走・Sub4達成したが、ダメージでかい。寒かった。 やらない勇気、休む勇気

7章 主要プラクティス

継続的インテグレーション

@ueda

CIの取り組みは今後の課題。

@got

コードリポジトリとビルドシステムの連携が未経験。

軽量なサンプルプロジェクトで試す。

「インテグレーションとビルドによって、完全なプロダクトを作り出す」って手作業によるムダをなくすという意味？

@kkd

2002年ごろは、自動テストを、ビルドサーバーで手動でテスト実行して、結果を確認していた。これもCI。

JUnitReportというのを使って、結果をレポートに出力して、Webで見れるようにしていた。

実行をスケジューリングで自動でやるようにした→レポート確認

JenkinsでいっきにCIが身近になった

ツールを使う＝CIではない。手動でやっても良いよー。

テストファーストプログラミング

@ueda

テストコードを書いていくうちに、最初の方のテストが不要になるケースもあって、でもリファクタリングせずにそのままになっていたり、あるいは別の目的で便利なので残しておいたり。

テストを書かなかった頃は、リズムなどなくてストレスばかりの作業だった。

テストを書いてリズムができた。

やらないといけないことに集中できる。 昔は、ブレークポイントを貼って地道に。。

@kobatomo

@t_wadaさんの資料はためになるよ。

テストは、質を上げない。質をあげるのは、プログラミング。

テストは、機会を与えてくる。ストレスを低下させてくれる。早いフィードバックで結果をくれるから好きなんです。

テスト駆動開発の付録Cをシェアしようと思う。

@got

数年前から自作分はあるべき姿を「一度に」テストを書いて開発・保守する方向へやっと遷移。

全方位に広がるテストコードの無いレガシーコードと戦いつつ、レガシーコードを増やさないよう学習中。

@kkd

TDDとテストファーストは違う TDD=Test First/Automated Testing/Refactoring/Evolutionary Design(進化的設計)/Simple Design

最初に小さいゴールを設定して、そこに進むことに集中することを繰り返していくことだなー。 ゴール駆動。

インクリメンタルな設計

@ueda（ですよね？自分で書いて忘れた...違ってたらごめんなさい

小さくて安全なステップで稼働中のシステムを変更する経験を積み重ねていく

最初のリリースはあくまでも試作で、そこからのリファクタリングが重要

言い換えると、何もない状態で詳細に設計をしたところで、実際に動かしてみないとわからないことが多い。

@got

「経済性」と「改善」

余計な「念のため」の設計を入れてしまい、それが足かせになってたことがあった。それらも少しずつ闇に葬ってはいるが、まだまだ途中。

「リファクタリング」は未読。

@kkd

インクリメンタル設計実現するには、テストとリファクタリングとシンプルデザインが必須だよねー。

生物の進化、胎児の成長をイメージしてください。

YAGNIを覚えておこう（You ain't Gonna Need It) ただし「どこまで」かの度合いはありますね。Railsに乗っかるとか、フレームワークとか

@kobatomo

ハードが絡むと難しい、と思っちゃう。

それから......

8章　始めてみよう

@kobatomo

変化は、気づきから始まる。

変化の必要性に気づけば、変化に着手できる。 気づきこれ超重要。気づくためのふりかえり。や勉強会の機会が大事だ。場は提供できるが、やるのは自分自身。

1. ペアプログラミングやっていると聞いたことがある。

2. ゆとりがないとできないよね。ということでやれていない。と回答をもらう。

3. 理解されないままだー。社内勉強会や、TDDBCを開いて、利点を共有する機会を作ろう。関係者がちょっとでもハッピーになれば自分も嬉しい。

変化は、常に自分のいるところから始まる。

gotさんが自分のタスクボードから始めたって話。いい。

自分もそう。最初始めたタスクボードは、まずは自分のプロジェクトから始めた。（もちろん、反対もあったと思う。これでいいのかと迷いながらやっていたときもあった）

やったことを共有する機会があってこんなことやっているんだーっで社内で発表。

やってみようという人がいて、だんだん浸透している。

今では普通になっている。

プラクティスをチームに強要すると、信頼関係を破壊して反感を買ってしまう。

TDDは、一人は続けている。一人でも共感してくれたことが嬉しい。

自分が、強要したからかもしれない。

テストを最初に書くことは難しい。で止まった。

テストの信頼性をどうしていくのかきちんと説明できていないからかもしれない。

@got

「変化」という言葉で始まる文。

新しい習慣の定着には時間がかかるものだ。 たとえ三日坊主になったとしても、自分に負けない気持ちが必要。4日目からでも再開できればうまくいく。

周りに左右されない自分自身のモチベーションって大事。 すごい大事！自分の速度！！

@ueda

変化に取り組むときは、一度に一つずつ着手

前向きに検討します（○○に取り組みます...と言い切れない（汗

メトリクス（測定法、尺度）が気づきにつながることもある。

数値化できていないなぁ... 訳者あとがき(P.169) XPはソーシャルチェンジ <<< これですよ！！！

@kkd

今いる所から始めて、プラクティスを追加しながら適応していくことになる

小さく始めよう！

プラクティスは、あなたの目的を達成するものであり、価値を表現したものである

プラクティスの裏の「目的」や「価値」も伝えよう！！

お互いに共有しないとすれ違っちゃうよ。

変化の速度

人それぞれ。

変化は気付きから（感情と直観と事実）

変化の必要性

変化は常に自分のいるところから始まる

プラクティスのマッピング

@kobatomo

マッピングのように可視化していないが、やっていると思った。あーでも原則は選んでいない。プラクティスを選んでいる。

後付けになるが、原則は、人間性(基本的な安全).

1. 導入したプラクティス。

定時で帰る。by 2017（いきいきとした仕事)

2. マッピング。

<症状>

焦り、不安、の症状を減らす。

コミュニケーションのやりずらさを減らす。

<ビジネス>

時間管理はする。どこで何を集中できる時間を見出す。

関係者とは、プロジェクト開始時にルールを決める。

お客様と電話する。

約束は守る。的を絞って２週間ごとにリリース。

<プライベート> 定時後の家族との時間。

新しい言語を学ぶ（Python)

本を読む時間を作る

社外の人との交流

3. 一人で進める

2017はやってみた。

4. 可能ならチームで共有する。

できていない。中々難しい様子。

@got

やってみてないです・・・ 書いてみます！

「排水管」ってなんだろう？（「窓の外に投げ捨てろ！」？） 英語だとDrains

失業の恐怖、退屈、非難 => 排水管

@ueda

仕掛かりですが...

@kkd

「いきいきとした仕事」のマップ日本語化されてないじゃん！！（kindleだから!!）

「いきいき」重要＝クオリティ 仕事だけじゃないよ！！　Quality of Life

結論

@kobatomo

チームを巻き込んでやりたいなぁー。

実施するには、プロジェクトリーダーとしての責任と役割が必要。第三者的な立ち位置でこれができるのかなー？

できるって信じる。やるかやらないかだ。↓

@kkd

可能性を信じることができるか？（＝信念）

今日のふりかえり

@ueda

何か新しいことをやろうとすると、リスクと捉えられたりして、じゃあ失敗したら責任取れるのか、みたいな雰囲気になって、新しい試みが難しい（かもしれない）。でも、そうじゃなくて何か新たな取り組みをすることでいくらでも可能性が広がるんじゃないかと。

「パターン,Wiki,XP」(P.84-86)と合わせてふりかえり

利用者からの要求を「ユーザストーリー」と呼び、ユーザストーリーを１回のイテレーションで開発可能な大きさの「タスク」に分解する

これが前回の @kobatomo さんの「テストがドキュメントになる」に繋がるのかな。それと @kkd さんが紹介された「YAGNI」もすぐ下に記述がありました。

どうせ必要にならないって！(You're NOT gonna need it!, YAGNI)

@kkd

安定は、変化をすることで安定する。

楽しいなぁ

@kobatomo

おー。やるかやらないかですね。そうそう。

信念を持ってやろう。

@got

やれることを少しずつ変化させていこう！

自分で考えてやれていることは、素敵です。王道です。(@kkd)

次回

2018/2/21 (水) 19:30 - 21:00

対象　

9章 導出プラクティス - 単一のコードベース

役割分担

司会 @kkd

connpass @ueda

wiki @got

hackmd @kobatomo

読書会のベロシティを測ろう。

今回は、８ページ